后话：PipeLine支撑运维自动化
读完需 5 分钟
速读需 2 分钟
严谨点
《CI/CD如何支撑运维自动化》主要讲述了我们在运维自动化方面的一些思路与实现方式，但后来经过仔细的琢磨发现应该将此称为“Pipeline如何支撑运维自动化”更为合适，因为我们的核心思路是通过对Pipeline进行编排，来实现不同的运维场景。
在此还有一个关键词：支撑，可能会有运维同学问，为啥不叫“实现”呢？
这个问题真的非常好，因为运维自动化是个很大的概念，这也意味着有很多不同的实现方式，而Pipeline只是其中的一种，故“支撑”而这里更加恰如其分。
请大家理解，如此的咬文嚼字正说明了我对“PipeLine支撑运维自动化”的重视，以及后续切实希望其在真正的工作中能够帮助到我们，这也是这篇“后话”的真正目的。
调研
运维的自动化离不开标准化，因此就有一个比较有趣的话题：
“先自动化再标准化 or 先标准化再自动化 ？”
经过初步的调研结果如下：
当我们在熟悉的领域时，“先标准化再自动化”是我们的第一选择，因为大部分的场景都经历过，知道处理问题的方式与方法。而当我们在不熟悉的领域呢？我们需要先去实践总结，这个过程可能就会选择“先自动化再标准化”。
因此对待这个问题我们要结合实际、理性看待、仁者见仁：
不同的选择在其相应的阶段都发挥着重要作用
做比说更重要
在此和大家分享我在进行运维自动化建设过程中坚持的一个理念：
结合公司当前自动化运维水平，以“先自动化，再标准化；边自动化，边标准化；既自动化，又标准化”为理念，实现标准化和自动化能力的交替上升，持续对外输出适合公司的运维技术和能力。
解决方案
通过对运维工作的不断梳理，我们将其总结成了如下的运维场景：
新服务器上架，与CMDB、监控、堡垒机联动同步；
操作系统初始化，包括用户、内核、安装源、规范目录、安全基线等；
基础组件初始化，包括Java环境、Pyhon环境、Nginx等各种组件；
应用版本发布、回滚，此过程与监控联动；
应用管理操作，如启动、停止、重启等；
监控系统实现服务器、应用等多个维度的监控与管理等
……
针对以上场景，我们如何如何选择解决方案呢？
1.成熟商业产品
虽然在一定程度上能够解决我们的痛点，但……
高额的产品费用
额外的人力成本
产品的稳定性、扩展性、可持续性
熟悉开发框架，满足后续功能扩展
2.自研运维平台
大局观上，功能要向主流标准看齐，但……
向主流标准看齐，需CMDB、ESB（企业服务总线）、对外API等，开发成本高
放低姿态，满足兼容性，对接各运维产品的API，差点意思
依赖稳定的开发团队，人力成本高
最终骑虎难下，难以维护
3.Pipeline支撑运维自动化
结合运维现状，借助Jenkins通过Pipeline对各种插件进行编排，实现各种场景的需求。
BlueOcean
Jenkins官方从用户角度出发，可使复杂的pipeline可视化，快速直观地理解管道状态
扩展共享库
通过共享库可以实现多个项目之间共享流水线，有助于减少冗余并保持代码干净整洁
Pipeline
流水线既可以作为job独立执行，也可以作为一项任务被其他流水线调用
通过以上三个方案对比，如果我们所在的公司没有足够的领导支持、成本投入、稳定的技术团队的情况下，那么"Pipeline支撑运维自动化"方案无疑将是我们优先选择的方案。
案例支撑
由于没有大佬背书或足够的案例支撑，小伙伴们可能对“PipeLine支撑运维自动化”的方案有所质疑，就连我曾经也认为这可能是一条野路子，可当我看到《SRE：Google运维解密》中介绍的Rapid系统时，我就更加确认了这套方案思路是正确的。
Google持续测试系统：Rapid ，每个Rapid项目都有一些工作流，定义了发布流程中的具体动作。工作流可以线性或者并发执行，某个工作流也可以启动另外一个工作流。Rapid将工作请求分发到运行在Borg系统上的生产服务器。
SRE: Google 运维解密
正如Rapid系统介绍，Pipelin支撑起了各个动作的具体实现，各条Pipeline还可以被其他Pipeline调用，非常的灵活。最重要的是还可以和Borg（Kubernetes 前身）结合，为我们后续在云原生领域的运维也提供了有效支持。